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Abstract :  Restricting  the  types  for  the  definition  of  the  key  of  a  relation  L41 
to  so-called  key  types  leads  to  a  subset  of  relations  -  called  key  re¬ 
lations.  Key  relations  can  be  implemented  efficiently  on  existing 
address-oriented  storage  devices. 

The  concept  of  a  key  type  is  introduced  and  applied  to  the  definition 
of  relational  databases  C5D.  It  is  shown  how,  by  means  of  key  types 
and  relations,  access  paths  -  e.g.  selectors  and  links  II5D  -  may  be 
defined,  created,  maintained  and  used. 

Key  types  and  relations  are  compared  with  reference  types  and  files. 

Key  Words  and  Phrases:  database,  data  type,  abstract  data  type,  relation,  access 
path,  reference,  file 

CR  Categories :  3.70,  4.22,  4.33,  4.34 


1,  Introduction:  Limitation  of  the  Relational  Concept 

Relations  are  by  now  widely  accepted  as  a  concept  for  storing 
and  retrieving  large  quantities  of  logically  related  data.  Relations 
as  defined  by  E.  F.  Codd  in  Cl:  or  as  introduced  into  high  level 
programming  languages,  e.g.  in  C4:,  show  however  at  least  two  major 
limitations : 

-  Semantic  information  constraining  the  data  to  be  stored  in 
relations  is  restricted  to  the  definition  of  the  component 
(tuple)  structure  and  of  the  key; 

-  Access  information  supporting  the  efficient  implementation  of 
relations  cannot  be  expressed  within  the  relational  concept  at 
all. 


This  work  was  supported  in  part  by  Deutsche  Forschungsgemein- 
schaft,  Bad  Godesberg,  W.  Germany 
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Instead  of  extending  the  notion  of  a  relation  to  express  addi¬ 
tional  constraints  we  apply  in  15'^  a  procedural  type  definition 
facility  (capsule  mechanism)  to  database  definition.  The  behavior 
of  a  capsule  is  defined  by  a  set  of  function  and  procedure  entries 
the  representation  is  given  by  a  set  of  local  variables  -  in  our 
application  mainly  by  relation  variables.  Capsules  are  a  very 
general  device  for  procedurally  expressing  the  semantics  of  a  data 
base;  however,  they  do  not  necessarily  contribute  to  an  efficient 
implementation  of  relational  systems. 

In  this  paper,  instead  of  extending  the  notion  of  a  relation  to 
express  access  paths,  we  will  design  means  for  specifying  a  sub¬ 
set  of  relations  that  can  be  mapped  efficiently  into  existing 
mass  memories.  They  are  thus  the  main  candidates  for  representing 
the  capsules  mentioned  above. 

In  chapter  2  we  introduce  so-called  key  types  which,  when  used 
to  declare  the  key  of  a  relation,  allow  an  efficient  implemen¬ 
tation.  The  usage  of  key  types  for  the  definition  and  mainte¬ 
nance  of  an  index  is  illustrated  in  chapter  3  by  an  example. 

In  chapter  ^  the  implementation  of  key  types  is  discussed. 

Access  paths  for  relations,  as  given  by  selectors  and  links 
c6d,  are  an  application  presented  in  chapter  5. 


2.  Key  Types  for  Relations 

Relation  types  are  defined  in  CU3  by  means  of  a  data  structure 
relation  and  by  record  types  specifying  the  tuple  structure  of 
a  relation.  Additionally  a  key  is  defined  by  a  field  identifier 
or  a  list  of  identifiers.  Attributes  identified  as  keys  are 
distinguished  by  the  fact  that  a  particular  key  value  occurs  at 
most  once  within  a  relation;  thus  keys  may  be  prefered  for  tuple 
identification. 

In  addition  to  scalar  and  string  types  admitted  for  the  tuple 
attributes  we  will  now  introduce  so-called  key  types.  The  re¬ 
lations  with  keys  defined  by  key  types  form  that  efficiently 
implement able  subset  we  are  looking  for. 


2.1  The  Data  Structure  key 

Key  types  are  defined  by  means  of  the  data  structure  key ,  by  an 
index  type,  and  a  relation  variable,  associated  with  that  key 
type . 

<key  type>  ;:=  key  <index  type>  for  <identifier> 

<index  type>  is  defined  in  the  sense  of  C23  p.  140,  i.e., 

either  a  scalar  or  a  subrange  type  but  not 
integer  or  real 

must  be  a  relation  variable  with  a  key  defined 
by  <key  type> 


< identif ier> 
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Example  2.1: 

type  vkeytype=  key  1,  ,100  fo^  rel; 

reotype=  record  .  .  .  ;  rkey:  rkeytype;  .  .  .  end; 
var  rel:  relation  <rkey>  of  rectype; 
reo:  rectype; 


The  relation  variable  rel  is  called  the  key  relation  associated 
with  the  key  type  rkeytype  j  conversely,  the  type  rkeytype  is 
called  the  key  type  associated  with  the  relation  rel.  A  rela¬ 
tion  associated  with  some  key  type  is  also  called  a  key  rela¬ 
tion. 

If  we  denote  the  values  of  a  key  type  by  circles  (o)  and  con¬ 
nect  equal  key  values  by  lines,  figure  2.1  shows  an  association 
between  the  variable  rec.rkey  of  type  rkeytype  and  the  key  rela¬ 
tion,  rel,  associated  with  that  type. 


Figure  2.1 

We  indicate  key  values  that  occur  in  the  key  field  of  a  key 
relation  by  full  circles  (• ) . 


2.2  Value  Sets  for  Key  Types 

Tv/o  standard  functions  keyval  and  indval  -  called  transfer  func¬ 
tions  -  map  the  ordered  value  set  of  the  index  type  of  a  key 
type  onto  the  ordered  value  set  of  the  key  type  and  vice  versa. 

If  reZ  is  a  key  relation  and  rkey  is  a  variable  of  the  key  type 
associated  with  rel  and  ind  is  of  the  index  type  underlying  that 
i^ey  type  then 

keyval  {ind,  rel)  is  the  key  value  with  the  index  value  ind 
indval  (rkey)  is  the  index  value  with  the  key  value  rkey. 

The  transfer  functions  keyval  and  indval  are  mutually  inverse, 

i .  e . 


key  valdndvaK  rkey )  ,  rel)  -  rkey 
indvaKkeyvaldnd y  rel))  =  ind. 


and 
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A  key  value  set  is  ordered  by 

rkeyl  <  rkey2  iff  indval  {rkeyl)  <  indval  {vkeyZ) , 

Furthermore,  the  two  standard  functions  pred  and  euca y  as  de¬ 
fined  in  C2D  for  index  types  are  extended  to  key  types  by 

pred(rkey)  =  keyval(pred(indval(rkey))); 

8uaa(rkey)  =  key val(  succ ( indval ( rkey ))) ; 

The  value  nemo  belongs  to  the  value  set  of  every  key  type,  how¬ 
ever  nemo  identifies  (as  a  key  value)  no  tuple  of  a  key  rela¬ 
tion  at  all.  The  functions  indval y  pred,  succ  are  not  defined 
for  nemo-valued  arguments.  The  functions  pred  and  succ  return 
the  value  nemo  when  called  with  the  minimal  or  maximal  key 
value.  Thus,  with  the  definitions  of  example  2.1, 

succ  (keyval  (100,  rel))  -  nemo . 

The  read  procedures  low(reZ)  and  next(reZ)  (see  CU3)  make  use 
of  this  fact;  when  that  tuple  of  key  relation,  rel,  with  the 
highest  key  value  has  been  accessed,  a  following  read  state¬ 
ment  next (rel)  makes  the  predicate  aor(rel)  true  and  assigns 
nemo  to  the  field  rkey  of  the  buffer  variable  re Z t  ,  thus  indi- 
cating  that  the  accessed  tuple  is  undefined. 

Example  2.2: 
type  .  ^ 

.  {definitions  and  declarations  as  in  example  2. 1) 

begin  loij3(rel); 

whi le  rel\.  rkey  ^  nemo  do 
begin  rec:=  rel^ ; 

.  {processing  of  rec) 

next  (rel) 

end 

end, 

2.3  Operations  on  Key  Types 


The  operations  defined  on  key  types  are  the  assignment  := 
and  the  relational  operations  =,  i,  >,  <,  >,  The  types  of 
both  operands  involved  have  to  be  the  same. 
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Example  2.3» 

.  [definitions  and  dealarations  as  in  example  2, 1} 

begin  . 

reo.rkey :=  keyval(7  yVel) ; 
reZ:+  Lrec]; 

•  \ 

lcw(rel)  ; 

while  (rel^ .vkey  i=-  reo.rkey)  ov_  (vel\ ,vkey  nemo)  do 
next(rel)  ; 

relf. rkey  ^  nemo 
then  begin  rea:=  rel\; 

.  {processing  of  reo) 


end. 


end 


2.4  Queries  Based  on  Key  Values;  A  Shorthand  Notation 


In  Lh3  we  introduced  a  predicate  oriented  query  facility  in  the 
form  of  a  general  relation  constructor.  Using  this  device  we 
may  construct  a  subrelation  of  the  relation  rely  constrained 
by  a  predicate.  Thus  the  relation  constructed  by 

Leach  rec  rel:  rec.rkey  =  keyval  (7,  rel)2 

holds  at  most  one  tuple  with  the  key  value  keyval  (7 ^rel)  ,  but 
may  also  be  empty. 

Now  we  introduce  a  shorthand  notation  for  the  case  that  a  sub¬ 
relation  of  a  key  relation  is  determined  by  a  key  value.  By 
analogy  with  the  access  of  array  components  by  subscripting 
the  array  variable,  e.g. 

A  Lindexvaluel 

we  access  components  (tuples)  of  key  relations  by  subscripting 
the  relation  variable,  e.g. 

R  <keyvalue> . 

The  accessed  component  is  of  the  record  type  underlying  the 
type  definition  of  R. 

Thus,  the  result  of  the  relation  constructor  above  is  also 
obtained  by 

Lrel  <keyval  (7y  rel)>l. 
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Unlike  an  array  access  a  relation  access  may  fail  if  the  com¬ 
ponent  identified  by  keyvatue  does  not  exist.  This  is  indi¬ 
cated  by  returning  a  null  result,  indicated  by  a  record  with 
the  value  nemo  for  the  key  type  attribute.  This  possibility  of 
denoting  null "records  exists  for  all  key  relations;  and  the 
shorthand  access  notation  is,  as  stated  above,  restricted  to 
these  relations. 

The  tuple  with  the  key  value  given  by  the  index  value  7  (example 
2.3)  may  now  be  retrieved  by 


rea:=  rel<keyval(7 yTel)>; 

if  vec,  rkey  ^  nemo 

then  .  .  .  [prooessing  of  reo]  .  .  . 


3.  An  Example:  Maintaining  an  Index 

We  will  apply  the  notion  of  key  types  to  an  example  given  in 
one  of  our  previous  papers 

A  record  type,  ereotype ,  is  defined  to  hold  descriptions  of 
employees : 

type  ereatype  =  record  enr  :  integer ; 

eatatue  :  (student^  technician, 

instructor y  professory 
emeritus); 
ename  :  string  end; 

In  order  to  store  a  variable  number  of  employee  descriptions, 
we  can  define  a  relation  type,  ereltype  ,  by 

type  ereltype  =  re lation  <enr>  of  erectype ; 

and  manipulate  a  variable  of  that  type,  say  erel  y  by  the  oper¬ 
ations  insert  (:+),  delete  (:-),  and  update  (:&)  defined  for 
relations . 

Alternatively,  we  can  define  a  class  type,  eclasstype ,  by 
Example  3.1: 

type  eclasstype=  class (<access  rights>) ; 
type  ...  ;  {definition  and 

...  ;  declaration  of  local  variables , 

function  .  .  .  ;  functions,  and  procedures] 

procedure,  .  .  ; 
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var  entry  status:  .  .  .  ; 
funotton  entry  value:  .  .  .  ;  begin  .  . 

procedure  entry  insert (  .  .  .  begin 

procedure  entry  delete (  .  ,  ,  begin 

procedure  entry  update (  .  .  .  );  begin 

begin  i 

.  {class  initialization) 


end; 

.  .  end; 
.  .  end; 
.  .  end; 


end; 

A  variable  of  type  eclasstype  ^  say  eclass  ^  is  manipulated  by 
its  procedure  entries  insert^  delete  and  update  The  function 
entry  value  provides  a  relational  view,  say  of  type  ereltype  ,  of 
the  employee  data  stored  in  eclase  ,  The  entry  status  holds  in¬ 
formation  on  the  success  of  an  insert,  delete,  or  update. 

Though  the  value  of  the  class  variable  eclass  is  given  by  the 
function  entry  value  as  a  single  relation  of  type  ereltype  ,  the 
data  may  internally  be  represented  in  a  different  way.  In  our 
example  we  will  store  the  employee  data  by  means  of  two  local 
relation  variables,  index  and  main.  Both  variables  are  declared 
to  be  key  relations.  Additionally  we  will  declare  two  record 
variables,  indrec  and  mainrec ,  and  two  variables,  freemain  and 
currentmain ,  to  be  used  for  the  explicit  management  of  the  free 
key  values  for  main.  We  assume  that  no  more  than  500  employee 
descriptions  have  to  be  stored  at  a  time. 

Example  3*2: 


type  indkeytype=  key  1,,500  index; 
mainkeytype=  key  1, ,500  for^  main; 
indrectype=  record  indkey:  vndkeytype;  enr:  integer; 

mainkey:  mainkeytype  end; 

mainrectype=  record  mainkey:  mainkeytype;  estatus:  integer; 

ename:  string  end; 

var  index:  relation  <indkey>  of  indrectype; 
main:  relation  <marinkey>  o?  madnrectype ; 
indrec:  indrectype; 
mainrec:  mainrectype; 

freemain:  re lation  <mainkey>  of  record  mainkey:  mainkeytype  end; 
currentmain:  mainkey type ; 
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Figure  3.1  shows  the  relationship  that  may  be  established 
between  the  variables  index,  indreo,  main,  and  mainrec , 


indkey  enr  mainkey 


< 

» 

•  •  • 

? - 

index 

( 

» 

•  •  • 

( 

1 

indreo 

mainkey  estatus  ename 


•  •  • 

•  •  • 

main 

mainreo 

( 

• 

•  •  • 

•  •  • 

Figure  3*1 

The  following  examples  of  procedures  maintaining  index  and 
main  will  explicitely  manage  only  the  key  values  for  the 
relation  main.  The  keys  for  index  are  supposed  to  be  managed 
by  the  function  getindexkey  of  example  3.3* 


Example  3«3» 


end; 

getindexkey  returns  the  value  nemo  if  there  is  no  free  key 
value  left  in  index. 

The  algorithm  associating  key  values  with  employee  numbers 
may  e.g. depend  on  the  order  of  the  employee  numbers  and  there¬ 
fore  rearrange  the  stored  associations  from  time  to  time,  or 
it  may  compute  an  index  key  value  out  of  an  employee  number 
using  hashing  techniques. 
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The  two  class  entries,  status  and  value,  may  be  given  by 


Example 


entry  status:  record  inserted,  deleted,  updated:  boolean  end^ 
function  entry  value:  ereltype; 

begin  value :=  \_each  (irec.enr,  mrec.e status,  mrec.ename) 

fo^  irec,  mrec  vn_  index,  main:  irec.mainkey  =  mrec.mainkey'} 

end; 


Generally,  an  effective  support  of  the  read  operations  -  in¬ 
cluding  the  relation  constructor  -  will  require  more  than 
one  function  entry,  reflecting  the  details  implemented  by  the 
altering  procedures.  This  problem,  however,  will  not  be  treated 
here . 

The  procedure  entry  insert  accepts  an  employee  description  of 
type  erectype  ,  initializes  the  two  record  variables  indrec  and 
mainrec  and  inserts  corresponding  tuples  into  the  relations 
index  and  main. 

Example  3»3- 

procedure  entry  insert (erec:  erectype) ; 
begin  if  some  vrec  in  index (irec.  enr  =  erec.enr) 
or  (getinde^ey  (erec.  enr)  -  nemo) 
then  status. inserted  :=  false 
else  begin  with  indrec  do 

begin  indkey:=  getindexkey (erec.enr) ; 
enr:-  erec.enr; 
low ( freemain ) ; 
iL  freemaini . freekey  ^  nemo 
then  begin  mainkey:=  freemain\,  freekey ; 
fre  emain:-^  L  freemai  n+  2 

end 

else  begin  mainkey:=  currentmain; 

currentmain : =  succ ( currentmain ) 

end 

end; 

index: Lindrecl; 
with  mainrec  do 

begin  mainkey:=  indrec, mainkey; 
estatus:=  erec.estatus ; 
ename:=  erec, ename 

end; 

main:-*"  Imainrecl; 
status,  inserted: =  true 

end 


end; 
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If  a  tuple  with  the  employee  number  presented  is  already  stored 
this  will  be  reported  through  the  Boolean  variable  status ,  inserted. 
The  lowest  key  value  of  mainkeytype  not  yet  used  is  held  in 
aurrentmain ;  the  key  values  which  are  freed  by  a  delete  are 
stored  in  the  relation  freemain .  A  new  key  value  is  acquired 
only  if  freemain  is  empty. 

The  procedure  entry  delete  removes  the  tuple  identified  by  the 
parameter  enr  from  index  and  the  corresponding  tuple  from  main. 

The  mainkey  value  of  the  latter  tuple  is  inserted  into  freemain. 

A  delete  failure  is  reported  through  status . deleted. 

Example  3«6: 


procedure  entry  delete (enr:  integer); 
begin  if  not  some  irea  in  index (ire c. enr  =  enr) 
zRen  status.  delet^:=  false 
else  begin  with  indrec  do 

begin  indkey:=  getindexkey (enr) ; 

mainkey : =  index<inS<ey> . mainkey; 
index:-  [,index<indkey>] ; 
main :  -  [jnain<mainkey>]  ; 
freemain :  +  [_( mainkey  )'\ 

end; 

status. dele  ted: =  true 

end 

end; 

For  an  update  it  is  only  necessary  to  locate  and  replace  the 
identified  tuple  in  main.  An  update  failure  is  reported  through 
status. updated. 

Example  3»7« 

procedure  entry  update (erec:  erectype) ; 
begin  if~not  some  irec  ^  index ( ire c.  enr  =  erec.  enr) 
then  status,  updated :=  false 
else  begin  with  mainrec  do 

begin  mainkey :=  index<getindexkey (erec. enr )>. mainkey; 
estatus:=  erec.estatus; 
ename:=  erec.ename 

end; 

main :  &  {jnainrec]  ; 

status,  updated :=  true 


end 
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The  body  of  the  class  definition  may  consist  of  some  initia¬ 
lizing  statements  for  the  local  variables  index^  mairij 
freemain^  and  currentmain ,  It  is  assumed  that  the  class 
eolasstype  has  access  to  an  external  class  restore  that  may 
be  used  for  backup  purposes. 


Example  3.8: 


type  eclasstype=  class (restore:  baokyptype ) ; 
type  ...  ;  {definition  and 

'^CL^  ...  ;  declaration  of  local  variables , 

function  .  .  .  ;  functions j  and  procedures} 

var  entry  ...  ;  {class 

function  entry  ...  ; 

procedure  entry  .  .  .  ;  entries} 
beg^n  index:=  re  store. index; 
main:=  restore. main; 
freemain:=  restore. f re emain; 
curren tmai n:=  res  tore . curren tmai n 

end; 


4.  On  the  Implementation  of  Key  Types 

The  main  reason  for  introducing  key  types  was  to  support  an 
efficient  mapping  of  the  data  structure  relation  into  storage 
structures  on  mass  memories.  As  long  as  large  associative 
memories  are  not  available  -  allowing  a  direct  implementation 
of  the  value-based  associations  stored  in  relations  -  a  mapping 
into  address-based  memories  has  to  be  implemented. 

It  is  claimed  that  key  relations  can  play  a  mediating  role  for 
this  mapping  process  because 

-  key  relations  can  be  used  to  implement  general  relations 
without  leaving  the  high-level  notion  of  relations  -  as 
demonstrated  by  the  example  in  section  3; 

-  key  relations  can  be  implemented  on  existing  storage  media 
efficiently  and  automatically  -  as  will  be  outlined  in  this 
section. 

Thus  the  value-to-address 
into  two  steps: 

(1)  general  attributes 


transformation  process  is  split 


procedurally 


e.g.  by  classes 
automatically 


key  type  attributes 


e.g.  by  compiler 


^  storage  addresses 


(2)  key  type  attributes 
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4.1  Keys  and  References 

In  the  most  simple  case,  the  key  values  are  the  storage  ad¬ 
dresses  themselves.  This  can  be  achieved  by  defining  the  trans¬ 
fer  function  keyval(ind,rel)  by 

keyvaldndf  rel)  =  base  address  (vel)  +  (ord(ind)  -  a.)  x  space  _per_tupte  (rel) 

ord(ind)  is  the  ordinal  number  of  ind  as  defined  in  C2D  p.  l6l, 
and  is  the  ordinal  number  of  the  first  element  in  the  value 
set  defined  by  the  type  of  ind. 

The  mapping  of  a  key  relation,  e.g.  ret  as  declared  in  example 
4.1,  is  outlined  in  figure  4.1. 

Example  4.1: 

type  rkeytype=  key  l.,n  for  rel; 

rectype=  record  rkey:  rkeytype;  fieldl:  .  .  .  ;  fieldn:  .  .  .  end; 
var  rel:  relation  <rkey>  of  rectype; 
rec:  rectype; 


For  the  purposes  of  this  paper,  we  will  assume  that  n  is  a  con¬ 
stant  known  at  compile  time. 


(a)  data  structure: 


1 - - - 

1 

rkey  fieldl  ...  fieldn 

' 

1 

1 

• 

•  •  • 

•  •  • 

•  •  • 

j 

• 

• 

• 

0 - 

-  1 

— • 

•  •  • 

•  •  • 

•  •  • 

rec.  rkey  i 

1 

1 

1 

• 

• 

• 

• 

•  •  • 

•  •  • 

•  •  • 

1 

1^  relation  rel 

Figure  4.1(a) 
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(b)  storage  structure: 

r 


space  _per_tuple  — ^ 


reo. rkey 


keyvaldj  rel) 

-  hase_address(rel)- 
(i  -  2) 

X  space _per_tuple( rel) 


inserted  fieldl 


fieldn 


2 


memory 

address 

register 


n 


true 

ft  ft  ft 

ft  ft  ft 

ft  ft  ft 

• 

ft 

ft 

true 

ft  ft  ft 

ft  ft  ft 

ft  ft  ft 

ft 

ft 

ft 

true 

ft  ft  ft 

ft  ft  ft 

ft  ft  ft 

addressable  memory  space 


relation  rel 


Figure  4.1(b) 


Key  values  in  a  key  relation  are  thus  represented  by  the 
addressing  hardware  of  the  memory  device  and  by  a  Boolean 
attribute  indicating  whether  the  tuple  with  that  key  value 
exists  in  the  relation  or  not.  It  should  be  noted  that  this 
method  of  implementing  key  types  is  restricted  to  the  keys  of 
key  relations,  i.e.  of  the  relations  associated  with  key  types. 

In  all  other  cases  attribute  values  -  key  type  or  not  "  have  to 
be  stored  explicitly. 

More  generally,  the  transfer  function  keyval  (ind,  rel)  maps 
the  index  value  set  into  some  logical  address  space. an 
example,  let  keyval  (indy  rel)  be  the  identity  function  that 
maps  its  parameters  into  the  logical  address  value  given  by 
the  pair  (ind,  rel).  This  pair  has  to  be  translated  into  a  ^ 
physical  address  at  runtime  by  paging  or  segmentation  techniques. 

Thus,  from  an  implementor’s  point  of  view,  a  key  value  may  be 
regarded  as  a  reference  to  some  -  logical  or  physical  -  storage 

location. 
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4.2  Relations  and  Files 


Normally  memory  space  for  relations  will  be  allocated  on 
external  storage  media  and  administrated  as  files. 

The  various  sorts  of  files,  such  as  sequential  files,  direct 
access  files,  and  indexed  files  correspond  closely  to  key  rela¬ 
tions  and  vice  versa.  Thus,  the  relation  rel  defined  in  example 
4.1  corresponds  to  a  file  with  up  to  n  elements'  of  type  reotype. 

Example  4.2:  Sequential  access 

Reading  the  relation  rel  by 


low (rel) j 

while  not  aor(rel)  do 
begin  . 

.  {processing  of  re  It} 

next (rel) 

end; 

corresponds  to  a  sequential  file  access. 


Example  4.3»  Direct  access 

If  rec  is  a  record  variable  of  type  rectype  (example  4.1)  and 
i  is  an  integer  variable  with  1  <  ^  ^  then 

rec:=  rel<keyval(ijrel)>; 

accesses  the  tuple  with  the  key  value  corresponding  to  the 
index  value  i  ,  and  assigns  it  to  rec,  A  tuple  with  that  key 
value  may  not  exist  in  rel;  this  is  indicated  by  reo,rkey  = 
nemo. 

Writing  on  a  direct  access  file  corresponds  to  the  three  altering 
operations  defined  for  relations  insert  :+,  replace  delete 

(1)  insert: 

By  rel  ; +  Lrecl;  a  tuple  copied  from  rec  is  inserted  into  rel 
iff  rec.rkey  introduces  a  new  key  value.  This  corresponds  to  a 
write  operation  on  a  file  that  is  protected  against  overwriting. 

(2)  replace: 

By  rel  :&  Crec^;  an  existing  tuple  with  a  key  value  equal  to 
rec.rkey  will  be  replaced  by  a  copy  of  rec.  This  operation  does 
not  correspond  directly  to  any  file  operation. 
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(3)  delete: 

By  vel  ;  an  existing  tuple  equal  to  vec  will  be  deleted. 

This  corresponds  to  a  file  operation  overwriting  an  element  by 
a  null  element. 

Example  ^.4:  Indexed  access 

Indexed  access  is  demonstrated  by  the  various  examples  of 
section  3. 

The  general  relation  constructor  provides  additionally  a  compact 
notation  for  accessing  a  relation,  e.g.  main ^  via  another  rela¬ 
tion,  e.g.  index.  If  index  holds  the  employee  names  instead  of 
the  (unique)  employee  number  (see  example  3.2)  then 

{^aah  mrec  in  main:  some  irec  i^  indexi (ireo.ename  -  name) 

and  (ireo.mainkey  =  mrec,mainkey )  )'] 

denotes  that  subrelation  of  main  holding  employee  descriptions 
with  a  given  name. 


4.3  Storage  Allocation  and  Reallocation 


The  declaration  of  a  key  relation  holds  all  the  information 
to  determine  the  maximal  storage  space  required  for  that  rela¬ 
tion.  Key  relations  where  the  product  of  'cardinality  of  the 
index  value  set’  and  'storage  space  per  tuple’  is  small  may  be 
held  in  the  main  memory  and  may  be  implemented  by  arrays  or 
records . 

The  storage  required  for  key  relations  may  be  allocated  piecewise 
and  on  demand.  For  an  example  consider  the  statement 

index  :+  ^indreal ; 

of  example  3.5.  It  inserts  a  one-tuple  relation  with  the  new 
key  value  indrec . indkey  into  index.  As  soon  as  the  product 

(orddndvaKindkey )  )  -  ovddndvaKhighestJiey ^allocated) ) )  x  space jper_tuple 


exceeds  the  amount  of  space  already  allocated  new  blocks  have 
to  be  allocated  for  the  relation  index.  The  number  of  blocks 
needed  in  addition  are  determined  by 


(orddndvaKindkey) )  -  orddndval  (highest  _key  _allocated) ) )  x  space  j>er_tuple 

tuples  jperJ^lock 

Thus,  the  strategy  used  in  example  3-5  for  assigning  key  values 
lowest  key  value  first  -  should  result  in  a  reduction  of  unused, 
but  allocated  storage  space. 
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Rearranging  the  storage  occupied  by  a  key  relation  results  in  an 
alteration  of  the  mapping  between  index  values  and  storage 
addresses.  If  key  values  are  mapped  into  storage  addresses  by 
paging  techniques  those  alterations  are  confined  to  the  entries 
in  the  page  tables.  However,  even  in  the  most  simple  case  dis¬ 
cussed  in  section  4.1  when  the  key  values  are  the  storage 
addresses  themselves,  the  system  has  a  chance  to  keep  track 
of  the  alterations  implied.  If  the  instances  of  some  key  type 
are  known  -  e.g.  if  they  are  all  stored  together  with  the 
associated  key  relation  in  the  same  database  and  if  no  program 
using  this  database  is  active  -  their  values  can  be  changed 
consistently  whenever  the  associated  key  relation  is  rearranged. 


5.  Applications:  Selectors  and  Links 

As  an  application  of  key  types  we  will  demonstrate  the  implemen¬ 
tation  and  maintenance  of  selectors  as  defined  by  the  LSL- 
language  C6n. 

Selectors  and  links  are  access  paths,  either  to  a  set  of  records 
or  from  one  set  of  records  to  another.  Individual  records  are 
selected  or  linked  according  to  attribute  values  or  linking 
predicates . 

Selectors  and  links  may  be  defined,  created,  destroyed,  and 
used,  and  are  expected  to  be  maintained  automatically  whenever 
they  are  affected  by  inserting,  deleting,  or  updating  records. 

Example  5» 

A  selector  fatcats  forms  an  access  path  to  those  employees  with 
weight  ^  200  or  salary  ^  30  000  (see  c6d  p.  124). 

We  will  sketch  the  definition  of  a  class  employ ees type  and 
thereby  mainly  concentrate  on  the  definition,  creation,  usage, 
and  maintenance  of  the  selector  fatcats. 

Example  5»1» 

Employees  may  be  described  by  a  variable  of  type  empreotype  and 
employee  descriptions  stored  by  a  variable  of  type  empreltype, 

type  emprectype=  record  lastjiame,  first  name:  string;  .  .  .  ; 

salary,  weight:  znteger;  .  .  ,  end; 
empreltype=  relation  <last  name,  first  name>  si  emprectype; 


However,  to  store  employee  descriptions  and  access  paths  centrally 
and  to  use  and  maintain  them  consistently  we  will  define  a 
class  variable  of  type  employ eestype , 

The  gross  structure  of  this  type  is  outlined  in 
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Example  5»2: 


type  employ eestype=  class ( Kacaess  rights>); 
type  ekeytype=  key  !• ,n  for  evel; 

ereatype=  record  ekey:  ekeytype;  last  name,  first_name:  string; 

.  .  .  ;  salary,  weight:  integer;  .  .  .  end; 
var  erel:  re lation  <ekey>  erectype; 

selector:  re lation  <ekey>  o£^  record  ekey:  ekeytype  end; 
selector _creaWKr~ boolean; 

•  •  • 

function  getekey (namel,  name2:  string):  ekeytype;  begin  .  .  .  end; 
var  entry  status:  record  inserted,  deleted,  updated:  boolean  end; 
functzon  entry  fatcats:  empreltype;  begin  ,  .  .  end; 
procedire  entry  create ^selector;  begtn  .  .  .  end; 
procedure  entry  delete  selector;  beg^n  .  .  .  end; 
procedm^  entry  insertTemprec :  emprectype) ;  begin  .  . 
procedure  entry  delete(namel,  name2:  string);  begin  . 
procedure  entry  update  (emprec:  emprectype) ;  beg^n  .  . 
begin  . 

.  {class  initialization} 

end; 


Associations  to  be  stored  by  the  relation  variables  erel  and 
selector  are  shown  in  figure  5*1 


ekey 


selector  erel 


ekey 


weight  salary 


• 

•  •  • 

•  •  • 

•  •  • 

— • 

205 

20000 

•  •  • 

• 

•  •  • 

•  •  • 

•  •  • 

• 

2  34 

25000 

•  •  • 

• 

»  •  • 

•  •  • 

•  •  • 

— • 

250 

35000 

•  •  • 

• 

•  •  • 

•  •  • 

•  •  • 

— • 

170 

30000 

•  •  • 

• 

•  •  • 

•  •  • 

•  •  • 

•  •  • 

Figure  5.1 
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It  is  assumed  that  not  more  than  n  employee  descriptions  will 
be  stored  at  a  time.  The  function  getekey  is  supposed  to  ad¬ 
ministrate  the  key  values  for  erel  (compare  example  3.3) • 

Some  of  the  class  entries  will  now  be  discussed  in  detail. 

5.1  Creating  a  Selector 


By 

Example  5.3^ 

procedure  entry  create elector; 

begin  setector:=  {.each  (erec»  ekey)  for  erec  i^  erel: 

(erec,  weight  >  200)  or  (erec,  salary  >  30000)']; 
selector, created :=  true 

end; 

the  keys  of  the  actually  qualified  tuples  in  erel  are  assigned 
to  the  relation  selector ,  The  value  of  selector _^created  reports 

that  fact. 

5.2  Destroying  a  Selector 


Calling  the  procedure 
Example  5.^. 

procedure  entry  destroy  ^elector; 
pegin  selector :=  C 

selector _created:=  false 

end; 

destroys  the  access  path  stored  in  selector. 


5.3  Using  a  Selector 


The  function  entry  fatcats  returns  as  a  relation  of  type 
empreltype  that  subset  of  employee  descriptions  where  weight 
>  200  or  salary  ^  30  000. 

Example  5.5- 

procedure  entry  fatcats:  empreltype; 
begin  H  se lector _created 

then  fatcats :=  {each  (erec, las t_name^  erec,  first  name^  ,  ,  ,  ^ 

erec, salary y  erec, weighty  ...  7  for  erec  in  erel: 
some  erec  in  selector (srec,ekey  -  erec,ekey)] 
else  fatcats  :=  {each  (erecTZastjname y  erec,  firs t_name y  ,  ,  ,  y 

erec,  salary y  erec,  weighty  ,  ,  ,  )  for  erec  in  erel: 
(erec, weight  >  200)  or  (erec, salary  >  SOOOOlT 


end; 
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If  the  selector  has  been  created  it  will  be  used  as  an  index  by 
that  part  of  the  system  interpreting  the  general  relation  construc¬ 
tor.  Otherwise,  the  result  has  to  be  constructed  by  more  general 
and  less  efficient  algorithms  searching  sequentially  for  weight 
and  salary  values.  The  main  idea  behind  selectors  and  links  is 
that  a  user  program  ’’will  work  when  the  access  paths  are  defined 
whether  they  are  created  or  not.  When  access  paths  are  not  created 
performance  may  suffer"  (C63  p,  130). 

5.4  Maintaining  a  Selector 


As  a  last  example  we  will  show  how  selectors  may  be  maintained 
while  employee  descriptions  are  inserted.  The  problem  of  a  selector 
overflow  is  not  considered  in  this  example  (compare  example  3* *5) . 

Example  3*6: 


proaedure  entry  insert ( emprec : emprectype ) ; 
var  ereo:  ereotype; 

begin  if  some  erea  i^  ereZ( (erec»  last_name  -  empreo.  last_name) 

and  (ereo. first_name  -  empreo. first _ncane) ) 
then  status,  inserted: =  false 
else  begin  with  ereo  do 

begin  ekey:=  getekey  (empreo.  last  _najm ,  empreo.  first  _name)  ; 
las t_name :  =  empre o .  las t_name ; 
first  jyame  :=  empreo.  first_name; 

•  •  • 

salary  :=  empreo.  salary ; 
weight :=  empreo. weight ; 

•  •  • 

if  seleotor_oreated  and  ( (weight  >  200)  or 

(salary  >  ZOOOOTJ 

then  seleotor:-^  U&key)'}; 

end; 

erel:-^  {.ereo]; 
s tatus . inserted : -  true 

end 

end; 


Links,  associating  e.g.  employees  and  their  houses,  may  be  imple¬ 
mented  and  maintained  by  similar  techniques. 

Interfacing  databases  defined  by  classes  and  user  programs  is 
discussed  in  detail  in  C5:. 


6.  Concluding  Remarks 


Key  types  show  two  main  advantages: 
level  language  constructs,  however 
all  the  efficiency  characteristics 
an  address. 


conceptually  they  are  high 
the  implementation  provides 
of  the  low  level  concept  of 
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From  a  programming  language  point  of  view  keys  and  relations 
can  be  regarded  as  a  counterpart  of  the  concepts  reference  and 
file. 

In  the  development  of  high  level  programming  languages  containing 
references  a  continual  restriction  of  this  concept  is  noticeable. 
While  e.g.  PI  /I  allows  a  pointer  variable  to  refer  to  variables 
of  different  types  or  even  to  non-existing  variables,  a  pointer 
variable  in  Pascal  may  point  only  to  (dynamically  generated) 
variables  of  a  certain  type.  In  Euclid  C3^,  pointer  variables 
may  refer  only  to  components  of  a  so-called  collection  variable 
of  which  one  is  defined  for  each  pointer  type.  Collection  variables 
may  be  considered  as  ’implicit  arrays’,  pointer  variables  as 
indices  for  these  arrays,  and  dereferencing  pointers  as  subscripting 
arrays.  This  has  e.g.  the  advantage  that  for  program  verification 
the  proof  rules  for  arrays  may  be  carried  over  directly. 

Our  concept  of  a  key  type  is  equally  influenced  by  the  pointer 
concept  of  the  programming  language  Euclid  and  the  concept  of 
associative  access  in  relational  databases.  The  collection  variables 
of  Euclid  corresponds  to  the  key  relations  and  dereferencing  by 
’subscripting  an  array’  corresponds  to  querying  a  relation,  i.e. 
looking  for  a  tuple  with  a  given  key  value.  Replacing  arrays  by 
relations  and  subscripting  by  querying  has  -  amongst  others  -  the 
advantage  that  the ’dangling  reference  problem’  finds  an  elegant 
solution:  dereferencing  a  pointer  to  a  deallocated  object 
corresponds  to  a  query  identifying  no  tuple,  thus  returning 
the  empty  relation. 

From  a  database  point  of  view,  key  types  and  relations  should 
provide  the  means  for  implementing  databases  efficiently  and 
on  a  high  level.  Though  originally  designed  for  relational  systems, 
these  constructs  can  also  implement  links,  cursors,  currency 
indicators  etc.  It  remains  to  be  shown  whether  relations  and  keys 
can  contribute  likewise  to  hierarchical  and  network  data  models  - 
at  least  at  a  conceptual  level. 
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